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REMARKS 

Applicant has carefully reviewed the Office Action of June 3, 2004 and offers the 
following remarks and evidence in response thereto. 

Before addressing the new rejection, Applicant provides a summary of the present 
invention, along with evidence to help define the claim terms and clarify arguments used herein. 
The present invention is designed to allow media gateways and media gateway controllers that 
reside on separate IP networks to communicate with one another. The media gateway and media 
gateway controller communicate with one another via control protocol messages. An exemplary 
control protocol is MEGACO. Because it appears that the Patent Office does not understand 
where the control protocol message exists in the protocol stack, a more detailed explanation is 
provided. 

When refemng to protocol stacks, many people of ordinary skill in the art refer to the 
Open System Interconnection (OSI) model, which has seven layers. TCP/IP does not exactly 
correspond to the seven layers of the OSI mode], but the analogy is close. See, for example, 
Wikipedia's online discussion of the Internet Protocol Suite found at 
http://en.wikipedia.org/wiki/TCP/IP, a copy of which is attached as Exhibit A. Even in a 
simplified form, TCP/IP is generally construed as having at least five layers that are analogous to 
layers within the seven layer OSI model The difference between the five layer model and the 
seven layer model is that in the five layer model, the top three layers of the OSI model are 
typically considered a single Application layer (see Wikipedia's explanation). 

Against this explanation of a protocol stack, it is worth noting that control protocols, and 
MEGACO specifically, are placed in the Application layer by those of ordinary skill in the art. 
See, for example, the description of MEGACO on page 3 of the ipGen document attached as 
Exhibit B, wherein the MEGACO stack is clearly positioned above the TCP or UDP transport 
layer. The TCP or UDP transport layer is described as being in layer four in the Wikipedia 
explanation, and thus, the MEGACO protocol is above the fourth layer. Note also that page 1 of 
the ipGen publication describes MEGACO as a control protocol between the media gateway 
controller and the media gateway. By extension, it is understood that the control protocol is an 
Application layer protocol. If additional evidence is required to prove that control protocols are 
positioned in layer 5 or above in the TCP/IP stack, Applicant can so provide such evidence 
through a declaration or the like. However, the evidence represents the understanding of 
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someone of ordinary skill in the art for the term "control protocols Specifically, this evidence 
proves that a control protocol in the context of the claim is a high level protocol that is positioned 
above the TCP or UDP transport layer. To date, the Patent Office has provided no evidence to 
controvert Applicant's definition, and specifically the Patent Office has not shown a control 
protocol that is not in the Application layer. 

Because the control protocol is a high level protocol, it is typically "buried" fairly deep in 
the protocol stack, and may be surrounded by text while being expressed as a number, such as 
10-1,2.3. The present invention parses the packet to find the control protocol layer, finds the IP 
address buried therein, converts the IP address, and places the converted address back into the 
packet. The conversion or translation of the IP address is done via a network address translation 
(NAT) scheme. 

It is worth noting that the PPP connection of Zhang et al- is a transport or hardware layer 
in the protocol stack - specifically layer 2, and is lower in the stack than the control protocol 
messages. Further proof of this is found in the Wikipedia document, page 2, which identifies 
PPP as a layer 2 protocol. Thus, as previously explained, Zhang et al., which peiforms network 
address translation (NAT) on a PPP message, does not perform NAT on a control protocol 
message as recited in the claims of the present application because under no reasonable 
interpretation of the term "control protocol" by someone of ordinary skill in the art would the 
PPP be a control protocol 

Applicant now turns to the particulars of the Office Action of June 3, 2004. Claims 1, 2, 
7, and 9 were rejected under 35 U.S.C. § 102(e) as being anticipated by Zhang et al. (hereinafter 
"Zhang")* Applicant respectfully traverses. For the Patent Office to establish anticipation, the 
reference must show each and every claim element. Further, the elements of the reference must 
be arranged as claimed. MPEP§2131. 

Applicant notes that in the Office Action of January 30, 2003, the Office Action of May 
27, 2003, and the Office Action of December 18, 2003, the Patent Office admitted that Zhang did 
not teach a control protocol Applicant finds it inconsistent that the Patent Office previously 
admitted that an element was missing and now opines that the element is taught by the reference. 
The Patent Office now opines that the control protocol message is taught by Zhang at column 6, 
line 42, Applicant traverses this assertion. Column 6, line 42 indicates that a packet is received 
from the user. There is no indication that the packet contains a control protocol message. Since 
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the reference does not teach that the packet has a control protocol message, the reference cannot 
anticipate the claims. 

Even if the Patent Office is correct in its assertion that the packet contains a control 
protocol message, the IP address within the control protocol message is not translated. The 
Patent Office opines that this element is taught by Zhang, column 6, Une 65-column 7, line 7 and 
column 4, lines 58-62; however, while these passages indicate that NAT takes place on the IP 
address, this is the PPP address, and not an IP address within a control protocol message. Proof 
that the address translation is a PPP translation and not a control protocol translation can be seen 
at column 5, lines 54-56 of Zhang, wherein it notes that the user has a PPP connection to the 
gateway. 

As explained above, translating an address in the PPP layer is not the same as translating 
the address in the control protocol layer. To this extent, claims 1, % 7, and 9 cannot be 
anticipated by the reference and are allowable. 

During the telephonic interview of March 3, 2004, Applicant explained the difference 
between the PPP layer and the control protocol layer. The Patent Office, in its Response to 
Arguments, opines that the features upon which Applicant relies for this argument are not recited 
in the claims. Applicant respectfully traverses. While the Patent Office is entitled to give claim 
terms their broadest reasonable interpretation, that interpretation is limited by two things. First, 
the interpretation must be reasonable. Second, the interpretation must be one consistent with one 
given to the claim term by someone of ordinary skill in the art. MFEP §2111.01. The term 
"control protocol message" has specific connotations to someone of ordinary skill in the art as 
evidenced by Exhibits A and B attached to the current response. 

The Patent Office's misunderstanding of the TCP/IP stack is highlighted by the Patent 
Office's statements on pages 2-3 of the Office Action, wherein the Patent Office opines that the 
TCP/IP stack only has 4 layers. This is demonstrably false, as proven by the concurrently 
submitted evidence. If the Patent Office truly believes that the TCP/IP stack only has four 
layers, Applicant invites the Patent Office to provide proof of this assertion, and then identify 
where in the stack the control protocol message is as compared to the PPP message of Zhang. 
Absent such evidence, the Patent Office is improperly reading an element out of the claims. 
While limitations from the specification are not read into the claims, the Patent Office's reading 
of the claims takes an element out of the claims - namely, the control protocol message. If 
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Applicant had meant any message, then the term "control protocol" would not be in the claim. 
The Patent Office's interpretation gives the term u control protocol" no weight. However, the 
basic tenents of claim construction require that all terms in the body of the claim have meaning, 
and the Patent Office is not entitled to ignore such terms. All of the claims recite a control 
protocol message, and thus the Patent Office is not free to ignore this claim language. To 
summarize, a control protocol message, as that teim is understood by one of ordinary skill in the 
art, is not taught or suggested by Zhang. 

With regards to Applicant's remarks about the interview in the previous response filed 
March 17, 2004, Applicant has reviewed his representative's notes from the interview and stands 
by Applicant's earlier comments. During the course of the interview, Applicant articulated an 
explanation of what the PPP was, what the control protocol was, and where they were positioned 
in the stack. The Examiner indicated that while a search would be required to determine if there 
was a reference that taught layer 6 translations, if the control protocol was part of the 6th layer, 
then the claim defined over the rejection of record. As Applicant noted in the previous response, 
the Examiner requested that these positions be presented in written form so that a new search 
could be performed based on those arguments. Applicant did so in the previous response. 
Applicant repeats this position in the present response, along with evidence to support 
Applicant's position that a control protocol message is an Application layer protocol and is thus - 
buried in the protocol stack. 

Having produced the evidence supporting Applicant's previous arguments, the burden is 
on the Patent Office to show that someone of ordinary skill in the art would construe the term 
"control protocol" differently. Absent such proof, the Patent Office has not satisfied its burden 
in proving anticipation. 

Claim 3 was rejected under 35 U.S.C § 103 as being unpatentable over Zhang in view of 
Cave. Applicant respectfully traverses. For the Patent Office to establish prima facie 
obviousness, the Patent Office must show where each and every element is located in the 
combination of references, MPEP § 2143.03. Further, before a combination may be proposed, 
the Patent Office must do two things. First, the Patent Office must articulate a motivation to 
combine the references. Second, the Patent Office must support the motivation with actual 
evidence. In re DembiczflK 175 K3d 994, 999 (Fed. Cir. 1999). 
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The Patent Office admits that Zhang does not teach that the node on the first network is a 
media gateway and the node on the second network is a media gateway controller. The Patent 
Office opines that such features are old and well known, as taught by Cave. While media 
gateways and media gateway controllers are old, Applicant is unaware of any reference that 
teaches a media gateway controller in a first network communicating with a media gateway in a 
second network. The Patent Office opines that Figure 2 of Cave shows a media gateway in a 
first network and a media gateway controller in a second network. Applicant respectfully 
traverses this assertion. The gatekeeper 236 and the gateways 224, 226 are all part of the same 
packet network 216. Therefore, the media gateway controller and the media gateway are not part 
of different networks, and thus, the combination does not teach all the claim elements. Since the 
combination does not teach all the claim elements, the Patent Office has not established prima 
facie obviousness. Since the Patent Office has not established obviousness, the claim is 
allowable. 

Applicant further traverses the combination of Zhang and Cave. The Patent Office 
opines that a person having ordinary skill in the art would have readily recognized the 
desirability and advantages of modifying Zhang by employing the communication of media 
gateways and media gateway controllers. The Patent Office goes on to state that these are 
common network nodes that may be available on any two communicating networks, and that 
they would benefit the system by providing service for multimedia communication. These 
assertions are not supported by the required actual evidence. Since the Patent Office has not 
provided the actual evidence that proves that there is a need for media gateways to communicate 
with media gateway controllers in a different network, the motivation is improper. Since the 
motivation is improper, the combination is improper , and the references must be considered 
individually. Zhang alone does not show all the claim elements, as admitted by the Patent 
Office. Cave does not show the NAT of the claim, and thus, is not sufficient to show all the 
claim elements. Since the references individually do not teach or suggest all the claim elements, 
the Patent Office has not established obviousness, and the claim is allowable. 

Applicant still further traverses the rejection because the combination of references does 
not teach or suggest the translation of IP addresses within control protocol messages. As 
explained above, Zhang alone does not teach control protocol messages, or the translation of an 
IP address therein, likewise, Cave does not teach translation of control protocol messages, and 
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thus, the combination of Zhang and Cave does not teach translation of control protocol messages, 
and the Patent Office has not established obviousness. Since the Patent Office has not 
established obviousness, the claim is allowable. 

Claim 5 was rejected under 35 U.S.C. § 103 as being unpatentable over Zhang in view of 
Cave, and further in view of Moms. Applicant respectfully traverses. The standard for 
obviousness is set forth above. 

As explained above, the combination of Zhang and Cave is improper, and thus, the 
combination of Zhang, Cave, and Morris is improper. Since the combination is improper, the 
references must be considered individually. Individually, the Patent Office admits that the 
references do not teach or suggest aU the claim elements and cannot establish obviousness. 
Since the references individually cannot establish obviousness, the claim is allowable. 

Applicant further traverses the rejection because the combination does not teach or 
suggest that the media gateway .of a first network communicates with a media gateway controller 
of a second network. As explained above, the MG and the MGC of Cave are not in separate 
networks, and thus, Cave does not teach or suggest this element. Nothing in Morris cures this 
deficiency. Since the combination does not teach a claim element, the combination cannot 
establish obviousness, and the claim is allowable. 

Applicant still further traverses the rejection because the combination does not teach the 
translation of a control protocol message. As explained above, Zhang and Cave do not teach the 
translation of an IP address in a control protocol message. Nothing in Morris cures this 
deficiency. Since the combination does not teach or suggest the claim element, the combination 
cannot establish obviousness, and the claim is allowable. 

Applicant still further traverses the rejection because the combination of Mortis is not 
properly supported The Patent Office opines that the motivation is that the system would 
benefit by protecting the address translation server, which would necessarily contain information 
on the structure of the IP network that may be sensitive. However, this motivation is not 
supported by any evidence. Since the motivation is not supported with actual evidence as 
required by the Federal Circuit, the motivation is improper and the combination is improper. 
Since the combination is improper and the references individually do not teach or suggest all the 
claim elements, the Patent Office has not established obviousness, and the claim is allowable. 
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Claims 11, 13, 15, and 17-21 were rejected under 35 U.S.C § 103 as being unpatentable 
over Zhang in view of Morris. Applicant respectfully traverses. The standard for obviousness is 
set forth above- 
Applicant initially traverses the rejection because the combination does not teach the 
translation of an IP address within a control protocol message. As has been explained above, 
Zhang does not teach this claim element. Nothing in Moms cures the deficiency of Zhang, and 
thus, in combination, the two references do not teach or suggest a claim element. Since the 
combination does not teach or suggest a claim element, the Patent Office has not established 
obviousness, and the claims are allowable. 

Applicant further traverses the rejection because the motivation to combine the references 
is not supported with the requisite actual evidence. Specifically, the Patent Office opines that the 
motivation to combine the references is to protect the address translation server, which would 
necessarily contain information on the structure of the IP network that may be sensitive. 
However, the asserted motivation has no actual evidence to support the motivation. Since the 
motivation is not supported, the motivation is improper and the combination is improper. Since 
the combination is improper, the references must be considered individually, and as previously 
analyzed, the references individually do not teach or suggest all the claim elements. Since the 
references individually do not teach or suggest all the claim elements, the Patent Office has not 
established obviousness, and the claims are allowable. 

Applicant finally responds to paragraph 5 of the Office Action. The Patent Office asserts 
that Applicant did not comply with 37 C.P.R. § L 1 U(c) because the arguments presented on 
page 3, third paragraph of the previous response did not clearly point out the patentable novelty. 
Applicant disagrees. The quoted claim language clearly shows that each of the independent 
claims recites some form of "translating an IP address within a control protocol message." The 
following sentences of that response indicate that, as discussed above in that response, Zhang 
and Cave do not show this element. As the argument had been presented in the analysis of the 
other rejections, it was not repeated. If the Patent Office wishes Applicant to re-submit the same 
arguments, Applicant will so comply, but such is not required by 37 C.F.R. § 1.111(c). 

Applicant requests reconsideration of the rejection in light of the remarks presented 
herein. The Patent Office is not free to ignore the "control protocol" claim language. When the 
claim language is given its proper weight, it is clear that the references do not teach performing 
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NAT on an IP address within a control protocol message. Applicant earnestly solicits claim 
allowance at the Examiner's earliest convenience. 



Date: August 31.2004 
Attorney Docket: 7000-246 
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Internet protocol suite 



From Wikipedia, the free encyclopedia. 
(Redirected from TCP/IP) 



Internet protocol suite 



Application layer 


FTP 


SMTP 


HTTP 


IRC 


Transport layer 


TCP 


UDP 


SCTP 


ICMP 


Network layer 


IP 


IPv6 


ARP 


DHCP 



The Internet protocol suite 

is the set of protocols that 
implement the protocol 
stack on which the Internet 
runs. It is sometimes called 
the TCP/IP protocol suite, 
after the two most important protocols in it: the Transmission Control Protocol (TCP) and the 
Internet Protocol (IP), which were also the first two defined. 



Data link layer Ethernet Token ring FDDI 802.1 1 WiFi 



The internet protocol suite can be described by analogy with the OSI model, which describes 
the layers of a protocol stack, not all of which correspond well with internet practice. In a 
protocol stack, each layer solves a set of problems involving the transmission of data, and 
provides a well-defined service to the higher layers. Higher layers are logically closer to the 
user and deal with more abstract data, relying on lower layers to translate data into forms that 
can eventually be physically manipulated. 

The internet model was produced as the solution to a practical engineering problem. Hie OSI 
model, on the other hand, was a more theoretical approach, and was also produced at an 
earlier stage in the evolution of networks. Therefore, the OSI model is easier to understand, 
but the TCP/IP model is the one in actual use. It is helpful to have an understanding of the 
OSI model before learning TCP/IP, as the same principles apply, but are easier to understand 
in the OSI model. 



Contents 

1 Layers in the TCP/IP stack 

1.1 The Physical layer 

1.2 The Data-Link layer 

1 .3 The Network layer 

1 .4 The Transport layer 

1.5 The Application layer 

2 Implementations 

3 Related topics 

4 Readings 
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5 External links | 

Layers in the TCP/IP stack 

There is some discussion about how to map the TCP/IP model onto the OSI model. Since the 
TCP/IP and OSI protocol suites do not match precisely, there is no one correct answer. 

In addition, the OSI model is not really rich enough at the lower layers to capture the true 
layering; there needs to be an extra layer (the Internetworking layer) between the Transport 
and Network layers, Protocols specific to a particular network type, but which are run on top 
of the basic hardware framing, ought to be at the Network layer. Examples of such protocols 
are ARP, and the Spanning Tree Protocol (used to keep redundant bridges idle until they are 
needed). However, they are local protocols, and operate beneath the internetwork 
functionality; to place both groups (not to mention also protocols which run on top of the 
internetwork protocol, such as ICMP) all at the same layer can be confusing. 

The following diagram attempts to show where various TCP/IP and other protocols would 
reside in the original OSI model; 
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Application 


e.g. HTTP, SMTP, SNMP, FTP, Telnet, Ssh and Sep, NFS, RTSP 


6 


Presentation 


e.g. XML, XDR, ASN. 1 , SMB, AFP 


5 


Session 


e.g. TLS, SSH, ISO 8327 / CCITT X.225, RPC, NetBIOS, ASP 


4 


Transport 


e.g. TCP, UDP, RTP, SCTP, SPX, ATP 


3 


Network 


e.g. IP, ICMP, IGMP, X.25, CLNP, ARP, RARP, OSPF, RJP, IPX, DDP 


2 


Data Link 


e.g. Ethernet, Token ring, PPP, HDLC, Frame relay, ISDN, ATM 


1 


Physical 


e.g. electricity, radio, laser 



Commonly, the top three layers of the OSI model (Application, Presentation and Session) are 
considered as a single Application Layer in the TCP/IP suite. Because the TCP/IP suite has no 
unified session layer on which higher layers are built, these functions are typically carried out 
(or ignored) by individual applications. A simplified TCP/IP interpretation of the stack is 
shown below; 



e.g. HTTP, FTP, DNS 

(routing protocols like RIP, which for obscure reasons run over UDP, 
may also be considered part of the network layer) 



Application 

"layer 7" 
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e.g. TCP, UDP, RTP, SCTP 
4 Transport (routing protocols like OSPF, which run over IP \ may also be considered 
part of the Network layer) 

For TCP/IP this is the Internet Protocol (IP) 
3 Network (required protocols like ICMP and IGMP run over IP, but may still be 
considered part of the network layer; ARP does not run over IP) 

2 Data Link e.g. Ethernet, Token ring, etc. 

1 Physical e.g. physical media, and encoding techniques, Tl , El 



The Physical layer 

The Physical layer describes the physical characteristics of the communication, such as 
conventions about the nature of the medium used for communication (such as wires, fiber 
optic links or radio links), and all related details such as connectors, channel codes and 
modulation, signal strengths, wavelength, low-level sychroni2ation and timing and maximum 
distances. 

The Data-Link layer 

The Data link layer specifies how packets are transported over the physical layer, including 
the framing (i.e. the special bit patterns which mark the start and end of packets). Ethernet, for 
example, includes fields in the packet header which specify which machine or machines on 
the network a packet is destined for. Examples of Data-link layer protocols are Ethernet, 
Wireless Ethernet, SLIP, Token Ring and ATM. 

PPP is a little more complex, as it was originally specified as a separate protocol which ran on 
top of another data link layer, HDLC/SDLC 

This layer is sometimes further subdivided into Logical Link Control and Media Access 
Control. 

The Network layer 

As originally defined, the Network layeT solved the problem of getting packets across a single 
network. Examples of such protocols are X.25, and the ARPANET'S Initial Connection 
Protocol 

With the advent of the concept of internetworking, additional functionality was added to this 
layer, namely getting data from the source network to the destination network This generally 
involves routing the packet across a network of networks, known as an internet. In the internet 
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protocol suife, IP performs the basic task of getting packets of data from source to destination, 
and also supports other protocols, such as ICMP (used to transmit diagnostic information 
about IP transmission) and IGMP (used to manage multicast data). ICMP and IGMP are 
layered on top of IP but perform network layer functions, illustrating an incompatibility 
between the internet and OSI models. 

The Network Layer Internet Protocol (IP) can carry data for a number of different higher level 
protocols. These protocols are each identified by a unique IP Protocol Number. ICMP and 
IGMP are protocols 1 and 2, respectively. 

The Transport layer 

The protocols at the Transport layer can solve problems like reliability ("did the data reach the 
destination?") and ensure that data arrives in the correct order. In the TCP/IP protocol suite, 
transport protocols also determine which application any given data is intended for. 

The dynamic routing protocols which technically fit at this layer in the TCP/IP Protocol Suite 
(since they run over IP) are generally considered to be part of the Network layer; an example 
is OSPF (IP protocol number 89). 

TCP (IP protocol number 6) is a "reliable", connection-oriented transport mechanism 
providing a reliable byte stream, which makes sure data arrives undamaged and in order, is 
re-transmitted if lost, and eliminates duplicate copies. TCP tries to continuously measure how 
loaded the network is and throttles its sending rate in order to avoid overloading the network. 
Furthermore, TCP will attempt to deliver all data correctly in the specified sequence. These 
are its main differences from UDP and can become disadvantages in real-time streaming or 
routing applications with high layer 3 loss rates. 

UDP (IP protocol number 17) is a connectionless datagram protocol. It is a ir best effort" or 
"unreliable" protocol - not because it is particularly unreliable, but because it does not verify 
that packets have reached their destination, and gives no guarantee that they will arrive in 
order. If an Application requires these guarantees, it must provide them itself, or use TCP. 

UDP is typically used for applications such as streaming media (audio and video, etc) where 
the time TCP requires for retransmission and re-ordering might not be available, or for simple 
query/response applications like DNS lookups, where the overhead of setting up a reliable 
connection is disproportionately large. 

Both TCP and UDP are used to carry a number of higher-level applications. The applications 
at any given network address are distinguished by their TCP or UDP Port Number. By 
convention certain well known ports are associated with specific applications. 

RTP is a datagram protocol that is designed for real-time data such as streaming audio and 
video. Although RTP uses the UDP packet format as a basis, it provides a function that is at 
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the same protocol layer. 
The Application layer 

The Application layer is where most common network programs reside. 

These programs and their corresponding protocols include HTTP (The World Wide Web), 
FTP (File transport), SMTP (Email), SSH (Secure remote login), DNS (Name <-> IP Address 
lookups) and many others. 

Applications most commonly run on TCP or UDP, and are often associated with a well-known 
port number. Some examples are: 

■ HTTP on TCP port 80 or 8080. 

■ SSH on TCP port 22, 

■ DNS lookups on UDP (or sometimes TCP) port 53, 

■ RIP routing updates on UDP port 520. 

These ports were originally allocated by the Internet Assigned Numbers Authority (IANA). 

Feel free to add to this list: DHCP (Kind-of), Echo, Finger, Gopher, HTTP, HTTPS, IMAP, 
IMAPS, IRC, NNTP, NTP, POP3, POPS, QOTD, RTSP, SNMP, SSH, Telnet, XDMCP. 

Implementations 

■ KA9Q 

Related topics 

■ List of well-known ports (computing) 
- OSI Model 

Readings 

Davies, Joesph and Lee, Thomas. (2003). Microsoft® Windows® Server 2003 TCP/IP 
Protocols and Services Technical Reference. Micosoft Press, Redmond Washington, USA. 

External links 

■ TANA home page (http://www.iana.org/) 
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■ IANA protocol 

■ IANA port numbers (http://www.iana.org/assignments/port-numbers) 

■ RFC 1122 {http://ietf.org/rfc/rfcll22) 

■ Introduction to TCP/IP (http://www.yale.edu/pclt/COMMtt - with some 
pictures 

■ RFC 793 (rfc793) - Transmission Control Protocol 
(http://www.faqs. org/rfcs/rfc 793. html) 

■ The basics of Transmission Control Protocol (http://tcp.mywebcities.com) 

■ Tcp/Ip port numbers. Information for Unix based system administrators 
(http://www. unixcities. com/tcp-ip-port-numbers/) 

■ TCP/IP FAQ (http://www.itprc.com/tcpipfaq/) 

■ TCP, Transmission Control Protocol 

(http://www. networksorcery, com/enp/protocol/tcp. htm) 

Retrieved from "http;//en.wikipedia.org^^ 
Categories: Internet | Network protocols 
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All text is available under the terms of the GNU Free Documentation License 
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duets & Services 



MEGACO 

MEGACO was developed by 
the ITU-T SG1 6 and IETF 
WG MEGACO and defines 
the control protocol between 
the media gateway controller 
(call agent) and the media 
gateway. The protocol 
provides: 




Protocol Stacks 
MEGACO 



MGCP 



SIGTRAN 



SIP 



Document Downloads 



Control for various types 
of terminations 
Support for negotiation 
of call capabilities 
Multi user call scenarios 
Rich termination dynamics 
Quality of Sen/ice (QoS)and traffic measurement 
support 

Error reporting on protocol, call, capability and 
network failures 



Integration of ipGen's MEGACO protocol stack in each 
customer's product will enable interoperability with media 
gateways and media gateway controllers utilizing the 
MEGACO protocol. ipGen's stack has a well defined and 
feature rich Application Program Interface (API) to the call 
control layer of Media Gateways and Media Gateway 
Controllers, This API enables rapid integration in each 
product and timely network deployment. ipGen also offers 
integration and customization services to assist integrating 
the protocol stack into each customer's product 



ipGen's MEGACO Stack Benefits 

•in 

m Scalability of system resources and performance # 
limits with configurability of system stack parameters e 

■ Separate compilations for Media Gateway and m 
Media Gateway Controller stacks so that high code 
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efficiency is achieved 

■ A small code footprint for Media Gateways 

■ Supported on multiple OS platforms including 
Solaris, Linux, Lynx, and Windows NT 

■ Well defined API to interface with the Call 
/Connection Control layer 

■ Sophisticated Application Layer Framing 

- Both TCP and UDP supported 

■ Re-transmission of transaction requests and 
responses 

■ Three way handshake supported 

■ Dynamic calculation and adjustment of 
response times to avoid network congestion 

■ Provisionable response timer 

■ Robust design 

■ Zero buffering of payload within the stack to 
achieve high performance 

- Reentrant and multi-thread safe API design 

■ Logically separated OS Layer to ensure easy 
portability to different operating systems 

■ Minimal inter-functional block communication 
(minimal IPC overheads) 

■ Efficient timer management and highly efficient 
memory management 

■ Comprehensive debugging support 

■ Multi-level Trace support and configurable 
History buffer recording 

- TMM data collection tuned to SNMP MIB 

■ Error log for both asynchronous and transaction 
related errors 

■ Interim AH security support 

■ Dynamic registration/de-registration of destinations 

■ Fault tolerance Support 

■ Mate health monitoring 

■ Fail-over mechanisms 

■ Equalization 

■ Application configurability for active change 

■ Availability of automated testing tools to test stack 
functionality 
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